Back to Blog

I Built A Training UI And Then Unsloth Laughed

I decided to build a training interface. A backend. A way for people to fine-tune models without touching a terminal. It sounded simple. It was not simple. It is currently the hardest thing I have ever done and I once tried to explain transformers to my cat.

We are four people working on this. Four. That should be enough right? A small team. Dedicated. Motivated. We have been at this for months. We are not even halfway done. I have a login page. I have a database that sometimes works. I have a queue system that loses jobs if you look at it wrong. I was feeling pretty good about our progress until I opened Twitter.

The Unsloth Reality Check

Unsloth announced their platform updates. They are backed by YCombinator. They claim 30x faster fine-tuning with their exclusive kernels [[11]]. They have 3x faster training with custom RoPE and MLP Triton kernels [[4]]. They support 500K context training [[1]]. They have MoE training that is 12x faster [[3]].

We have four people and a dream. Unsloth has funding and a team that ships updates like we ship bugs. They announced faster reinforcement learning support in late 2025 [[5]]. They integrated with NVIDIA Blackwell GPUs [[10]]. They have Docker images that work out of the box [[18]].

Building a tool is hard. Building a tool while a YCombinator-backed company announces features you have not even thought of yet is a special kind of hell.

The Team Situation

4
People on our team
0
Features we shipped this month

Four people should be enough. We have a backend developer. We have a frontend developer. We have someone working on ML infrastructure. We have me doing everything else and panicking constantly. We meet weekly. We assign tasks. We miss deadlines. We are still behind.

Unsloth probably has more engineers than we have total team members. They probably ship in a day what takes us a week. They probably have CI/CD pipelines that work. Ours breaks when someone pushes on a Tuesday.

Why Backends Are Hard

Training models is compute intensive. It takes time. It takes resources. Our backend needs to handle long-running jobs without timing out. It needs to resume if a GPU crashes. It needs to notify the user when something finishes three hours later.

We are using Celery. We are using Redis. We are using PostgreSQL. We are using prayers. The stack is held together by hope and stack overflow answers from 2019. Every time we fix one bug two more appear. It is like hydra but with more asynchronous code.

# Our current backend architecture in a nutshell
try:
    train_model()
except Exception as e:
    log_error(e)
    team_meeting()
    cry_collectively()
    restart_server()
    # Still does not work

The Feature Gap

Unsloth has multi-GPU support. We have one GPU shared between four people. Unsloth has embedding model support [[3]]. We barely have text model support. Unsloth has quantization-aware training [[1]]. We have quantization-aware panic.

I keep adding features to our roadmap that we cannot build. Collaborative workspaces. API access. One-click deploy. Billing. I saw them on the Unsloth roadmap and thought we need that too. We do not need that yet. We need the basic thing to work. But I cannot stop adding things because I am scared of being irrelevant.

Our Tiny Advantage

Unsloth is fast. Unsloth is optimized. Unsloth is professional. We are small. We are slow. We are confused. But we can make decisions quickly. We can change direction without a board meeting. We can add weird features because we think they are fun.

Maybe our tool will not compete on speed. Maybe it will compete on personality. Maybe it will be the training interface that admits it is struggling. Maybe users will like that. Maybe they will not. Maybe we are just rationalizing our inability to build a performant backend.

What Comes Next

We will keep building. We will trim the roadmap. We will remove features until we have something that works. We will focus on the core thing. Upload dataset. Train model. Download weights. If we can make that work reliably we will call it a win.

Four people should be enough. Four people is not enough. We are still behind. We are still coding. We are still trying. That has to count for something.

Until then we are just a small team with a roadmap that is too long and a dream that is too big. And that is fine. That is what hobbyists do. We build things that probably will not work. We build them anyway.